For tests you could just update the user guide to include some emojis. The user guide code blocks are run through test-doc-blocks.

Don't be too worried about CI failures, especially on Windows. That platform is still flakey on CI. Just rerun failed jobs.

For tests you could just update the user guide to include some emojis. The user guide code blocks are run through test-doc-blocks.

Thanks @lread ! I've added some emojis to the examples as suggested, but is it enough? As far as I'm aware there is no check that the "text" was actually typed correctly (or is there?)

Thanks @lread ! I've added some emojis to the examples as suggested, but is it enough? As far as I'm aware there is no check that the "text" was actually typed correctly (or is there?)

Ah yeah, good point! Could add in a fetch for the element value.

Also: thanks for fixing various typos as you notice them. I am the king of typos.

Windows CI is horribly flakey, as a Window guy, if you have any insights let us know.
My guess is that we might just need to increase timeouts for CI+Windows+GitHubActions.
But I dunno. (We have a separate issue for this #465)

@lread I've just uploaded a new test that follows the same pattern as fill human multiple inputs but works with emojis :) let me know what you think!

Also: thanks for fixing various typos as you notice them. I am the king of typos.

my pleasure :)

Windows CI is horribly flakey, as a Window guy, if you have any insights let us know.

I can take a look, but I don't promise anything 😅 I'm using etaoin mainly from within WSL, but for the little I've used it in Windows I can't say I noticed any special delays or timeout errors 🤔 I wonder if the issue could instead be the CI environment you're using (browser or webdriver version could be out of date for instance).

Anyway, I'll try to run the "windows" tests on my local PC and see if there are any failures.

@lread I've just uploaded a new test that follows the same pattern as fill human multiple inputs but works with emojis :) let me know what you think!

Interesting! If you have trouble getting these to pass, an alternative might be to try updating user guide and add something like so:

(e/get-element-value driver :uname)
;; => "my fancy expected emojis"

Would that work? (this would become an assertion that test-doc-blocks runs)

I can take a look, but I don't promise anything sweat_smile I'm using etaoin mainly from within WSL, but for the little I've used it in Windows I can't say I noticed any special delays or timeout errors thinking I wonder if the issue could instead be the CI environment you're using (browser or webdriver version could be out of date for instance).

Anyway, I'll try to run the "windows" tests on my local PC and see if there are any failures.

Ya I suspect it is GitHub Actions (it stays up to date with browsers and drivers), I've not had much failure when running in my Windows VM. But if you take a peek, thanks in advance.

Interesting! If you have trouble getting these to pass, an alternative might be to try updating user guide and add something like so:

oh yes that's much nicer (and easier) than what I had done :) updated as suggested

Hmmm... I am trying this out in my REPL.
Emoji chars seem to fill nicely in Firefox but I get ?? in Chrome.
How about you @tupini07?

Ah we seem to maybe have the same codepoint issue for make-input*, I'll take a peek.

Ah, maybe sending emoji chars with ChromeDriver does not work?:
https://bugs.chromium.org/p/chromedriver/issues/detail?id=2269

I think chrome only currently supports Unicode in the Basic Multilingual Plane.

So, maybe ok. Different drivers/browsers have different limitations.

Could run this test under Firefox only.
Could add a note to user guide.

I expect Microsoft Edge would be the same as it is based on the same code as Chrome.
And Safari, we'd have to test.

@tupini07, I can take a peek at this if you like, I have all the necessary VMs setup to poke around.

@tupini07, I can take a peek at this if you like, I have all the necessary VMs setup to poke around.

@lread thanks for the investigation! Yeah it does sound like chromedriver has a limitation, interesting. I'm not home now so I can't test on my end wether this happen on my chrome as well.

And yes sure! If you want to look into it that would be great! As I said I'm not homj right now, and probably won't be able to work on this until tomorrow night :)

Ya, there is really no big rush. I can take a peek maybe tomorrow.

Thank goodness for VMs and remote REPLs!

My findings across OSes are:

• Safari works
• Firefox works
• Chrome works for BMP only
• Edge works for BMP only

I'll likely follow up tomorrow.

Ok @tupini07, what do you think of my small tweaks to your fine effort?

@lread wonderful! Thanks a lot for your help 🤗 it would have taken me ages to work out how to properly test this and all the other changes you did. Also, great catch with this needing to be added to make-input* as well!

This PR has my name but basically you were the one who implemented everything 😅

Thanks for reviewing @tupini07, I shall merge.
Don't sell yourself short, you did good work here, let's call it a collaboration then, eh?
Thanks for your contribution here, much appreciated!